1. Field of the Invention
The present invention relates to computer software, and deals more particularly with a method, system, computer program product, and method of doing business with automated electronic business services by using a structured markup language processing engine and structured markup language documents. The disclosed techniques may also be used advantageously for automating other types of applications that can be described using finite state machines.
2. Reservation of Copyright
A portion of the disclosure of this patent document contains material to which a claim of copyright protection is made. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but reserves all other rights whatsoever.
3. Description of the Related Art
The market for electronic business-to-business, or “B2B”, commerce is growing rapidly, and has tremendous opportunities for improving business efficiency and profitability. This market is predicted to reach trillions of dollars per annum in the near future. At the same time, the electronic business-to-consumer, or “B2C”, market is also increasing substantially.
B2B and B2C commerce may be referred to more generally as electronic commerce or electronic business (or equivalently, “e-commerce” or “e-business”). To enable wide support for e-business, it is necessary to have cost-efficient application software that supports business transactions. One prior art technique for electronically exchanging information between businesses is EDI (Electronic Data Interchange), which has been in use for a number of years. However, EDI support is relatively expensive to provide, and the protocols used in EDI transactions are not easily extended for new business applications. EDI has therefore not been widely utilized for providing e-business solutions in today's Internet and World Wide Web (hereinafter, “Web”) environments.
A more commonly-used technique for providing e-business solutions is for business partners to electronically exchange information using electronic documents encoded in a structured notation such as the Extensible Markup Language (“XML”). XML is often used to represent the data content being exchanged, and may also be used to specify what type of request or response is being transmitted within the scope of a particular business application. (As an example, an XML document may contain markup tags indicating to the receiving application that the document contains data for a purchase order by using an attribute and value such as Request_Type=“purch_order”.) When XML is used to specify a request for a business service or a response thereto, the manner in which the service and its associated information processing is actually carried out remains hidden from the partner which initiates the request, but the implementation at the receiving partner is often quite complex. Similarly, in B2C transactions, the details of carrying out a consumer's request may be quite complex, but the client software used by the consumer is typically shielded from this level of detail and may interface with the back-end application by simply formatting the request in the proper manner.
The actual implementation of an e-business service may require execution of many sub-services, each of which may also invoke sub-services. Furthermore, the sub-services may initiate interactions with other business partners, including the original initiator of the service request. Therefore, defining and managing the service implementation for carrying out e-business transactions, including the interactions of the required sub-services, can be a very challenging problem.
Prior art techniques for implementing e-business solutions typically require intensive programming efforts. For example, programming that is customized to a particular business application is required for integrating the sub-services of the application such that a service is properly executed. Sophisticated tools are often required to assist the programmer, and a tight dependency will be created between the generated code and the run-time system infrastructure. The portability, reusability, and cost associated with using the resulting solution creates another problem.
One approach for specifying data and process interaction protocols that is currently being used in the industry for e-business solutions is to use trading partner agreements. A trading partner agreement, or “TPA”, is a document that describes the general contract terms and other parameters under which two or more business partners will communicate electronically for a particular set of business transactions. For example, the communication and security protocols to be used for electronic interchanges must be specified and agreed upon, including the types and formats of messages that are valid, codes and parameter values to be used in those messages, and so forth. Structured markup languages derived from XML are being defined and standardized for expressing TPAs, in order to enable businesses to automate the TPA exchange process. Example notations include “tpaML” (Trading Partner Agreement Markup Language) and “cXML” (Commerce XML).
When using tpaML, for example, one business partner creates a TPA (using either a text editor of some type, or perhaps a specialized TPA creation software tool), and sends an electronic copy of the resulting tpaML document to a second business partner. The second business partner adds its own information to the tpaML document (such as a bank account number for use in transactions covered by this TPA, the range of dates for which the TPA is in effect, etc.), and returns the tpaML document to the originating partner. Once a complete and agreed-upon TPA has been created, the tpaML document is processed by a code generator at each business partner's site to produce software to control subsequent B2B transactions between these partners for this computing application.
tpaML was originally developed by the International Business Machines Corporation (IBM), and is now being standardized by the Electronic Business XML Initiative or “ebXML”. ebXML is an organization devoted to defining global e-business standards, and is sponsored by the United Nations and the Organization for the Advancement of Structured Information Standards, or “OASIS”. For more information on tpaML, see http://www.ebxml.org on the Internet.
cXML, on the other hand, is used to define information about a product in order to standardize the exchange of catalog content and to define the request/response processes (such as purchase orders, payment transactions, etc.) for secure electronic transactions. (For more information on cXML, refer to www.cxml.org.)
While use of tpaML offers a number of advantages, it does not provide a complete solution for automating B2B and B2C transactions. For example, electronic interchange of tpaML documents and tool-generated code based upon the TPA content provides only a mechanism for interfacing the content of the TPA to existing business applications: it does not provide refinement for integrating the business data used by a service or the interactions for a set of services and sub-services that may be invoked during execution of the underlying business application software that supports a transaction among trading partners. (For example, the code generated from a tpaML document may convert the trading partner's bank account information into the format expected by an existing business application, and store the converted information in a particular predetermined location; create a billing parameters file in which the trading partner's billing information is stored, using the format expected by the existing business application; and so forth. However, the generated code does not provide procedures for such as ensuring that the bank account is valid before accepting a payment transaction: application-specific code must be provided to integrate the processing of this type of information into the overall application. Furthermore, the generated code does not provide procedures for accepting and coordinating input data for a transaction, nor for initiating the payment logic only after a complete order has been assembled, and so forth.)
More importantly, code generation tools generate code with dependencies to specific infrastructures or frameworks. The need to separate out the business logic that controls the data and process exchange flows was not contemplated nor accounted for in such tools. Thus, it is not easy to share a common piece of exchange business logic among different partner systems. This is also true within a business's own system environment if the framework or infrastructure is not the same throughout, such as when organizations are consolidated from business mergers. Handling of system growth issues such as service redirection, content redistribution, and server upgrades could become overly complex in such environments.
In addition, the requirement for processing tpaML documents with a code generator means that any changes to the TPA in place between business partners requires repeating this generation process, which may in turn require complex and expensive regression testing, code archiving, and administrative procedures. Furthermore, the tpaML approach may not extend well to the B2C marketplace, as the creation of TPA information may be too complex for the average consumer and the code generation software may not be readily adaptable to the client environment in the client-server paradigm typically used in B2C computing.
Another prior art technique that may be used with e-business transactions is to use a software work flow system. Examples include the FlowMark® and MQ Workflow products from IBM. (“FlowMark” is a registered trademark of IBM.) When using work flow as a modeling tool, a Flow Control Model (FCM) can be used by a business partner to visually define the interaction flows with other trading partners. The result can be an FCM formatted file which then needs to be further processed into a script file that specifies the particular service definition. However, a work flow tool is used primarily as a general programming concept such as flowcharting or structured programming. For example, building a model of business processes involves defining the processes, the work flow participants in particular organizations, and the information technology resources needed to implement the work flow. To complete the model, the domain expert must add processing logic, assign staff to a process, write customized code, attach the programs to the model, add data, and add information technology resources. After the model is completed, it needs to be imported and compiled into a form required for the run-time environment of the modeling tool, where execution of the processes will be driven from the tool's server components (or run-time environment). Such is the nature of a typical work flow system. There are several limitations with using work flow systems, however. The run-time environment of each modeling tool is typically proprietary, and thus is better suited to use in intra-company applications where the modeling tool will be readily available than for use in e-business transactions among different companies. In addition, work flow modeling tools tend to use proprietary data formats, which are also not well suited to the needs of e-business in an open distributed networking environment. Furthermore, user code must typically be plugged in to a complex and proprietary object model when using work flow modeling tools (often requiring the writing of application-specific integration code), in order to provide an executable application.
No prior art techniques are known to the inventors that support integrating services provided by different business partners to a transaction and integrating different information from multiple sources (such as the responses generated when various sub-services are invoked): typically, this type of integration must be provided by writing application-specific code. It would be preferable to have a technique for defining and managing e-business services and their interrelationships that could automatically integrate the underlying processing without writing customized software for each e-business application. Furthermore, this technique should be based upon non-proprietary data formats, protocols, and so forth, in order to assure wide acceptance in a global marketplace. Such a technique would make the tasks of developing and administering e-business solutions much easier and less expensive. As a result, the benefits of e-business would be available to more businesses, yielding significant benefits to the B2B and B2C marketplace.
Accordingly, what is needed is an improved technique for defining and carrying out automated e-business services that is easily adaptable to a wide variety of business applications, that does not require intensive programming for each particular application, and that is cost-efficient and independent of the infrastructure implementation of individual business partner systems.